Since they were introduced and started to be largely adopted in the 70's databases have proliferated in all sorts of domains including engineering, scientific, commercial and business applications. Their size can be anything ranging from a small database used by a single individual on a personal computer, e.g., to keep track of personal finances, to large and very large databases set up by various institutions, companies and commercial organizations to support their activity. In an all-interconnected world those large databases are also generally, if not always, made accessible to numerous remotely located end-users to query whatever information is made available by the databases.
In the airline industry, examples of such very-large databases are the ones that hold the airline fares along with the rules restricting their use. Fare databases are mainly set up by a few worldwide global distribution systems (GDSs) that provide travel services to all the actors of the travel industry including the traditional travel agencies and all sorts of other online travel service providers. Such a GDS is for example AMADEUS, a European travel service provider with headquarters in Madrid, Spain.
Those large databases have to sustain conflicting requirements. They must be operational in a 24-hour-a-day/7-day-a-week mode to sustain a worldwide business that never sleeps while they also need to constantly acquire new fares published by hundreds of large and smaller airline companies. As depicted in FIG. 1 the data providers (120), i.e., the airlines or the fare providers on behalf of the airlines, and the data requesters, i.e., the remote end-users of the database (100) are both trying to access simultaneously the same resource creating conflicts to answer queries while database contents are being updated.
Solutions that have been implemented to get around this problem include working in batch mode. That is, in one way or another, all received updates are prepared and accumulated until the database is disabled for end-users at regular intervals (e.g., each night or at scheduled intervals) to let administrators imbed all accumulated updates after which database is re-enabled and can resume answering end-user requests. This obviously however fail complying with the objective of sustaining a 24/7 mode of operation.
An alternative solution that has also been carried out is to implement a flip/flop mechanism. Two identical databases are maintained one serving to answer end-user queries while the other one is being updated. Like with the batch mode, at scheduled intervals, the roles of the databases are swapped. The obvious advantage of this solution is that there is no longer any down time for the end-users (or very little, while swapping takes place). However, none of these solutions allow propagating the incoming updates in real-time. The end-users will see the modifications only after, sometime, a long delay. Delay which essentially depends on the time interval set for the batch or flip/flop mode.
It is therefore the prime object of the invention to disclose a mechanism that allows a continuous integration of the updates received from the data providers and their propagation so that they are coherently and rapidly made available to answer queries from the end-users of the database.
Further objects, features and advantages of the present invention will become apparent to the ones skilled in the art upon examination of the following description in reference to the accompanying drawings. It is intended that any additional advantages be incorporated herein.